fix untagged enum automatic ordering#991
Open
Farossco wants to merge 1 commit intooxidecomputer:mainfrom
Open
Conversation
Farossco
force-pushed
the
fares/reordered_untagged_enum
branch
3 times, most recently
from
e446496 to
5da50fb
Compare
Signed-off-by: Farès Chati <fchati@smartandconnective.com>
Farossco
force-pushed
the
fares/reordered_untagged_enum
branch
from
5da50fb to
a79bf15
Compare
ndreno
added a commit
to barbacane-dev/typify
that referenced
this pull request
Mar 19, 2026
Cherry-picked from upstream PR oxidecomputer#991. When a schema defines an untagged enum with both integer and number types, serde tries variants in order. Having Number (f64) before Integer (i64) made the Integer variant unreachable since any integer is also a valid f64. Introduces ReorderedInstanceType to ensure Integer is always matched before Number during deserialization.
ndreno
added a commit
to barbacane-dev/typify
that referenced
this pull request
Mar 19, 2026
18 new runtime tests verifying actual serde behavior, not just codegen: - PR oxidecomputer#991: IntOrStr deserializes 42 as Integer (not swallowed by Number) - PR oxidecomputer#918: RequiredWithDefaults::default() has correct values; deserializing {} uses schema defaults - PR oxidecomputer#986: Dscp TryFrom rejects 64, accepts 0-63; serde rejects out-of-range JSON values - PR oxidecomputer#948: All 9 comparator symbols round-trip through serde correctly - PR oxidecomputer#414: anyOf with object+string+integer deserializes without panic - PR oxidecomputer#954: not:{type:"object"} accepts primitives; array items work Also fixes pre-existing CustomMap test compilation (missing Default and is_empty) and adds serde derive feature to typify-test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When parsing the following type of schema definition:
{ "definitions": { "Value": { "type": [ "array", "boolean", "integer", "number", "object", "string" ] } } }The following rust type is generated:
This is mostly what we want but the issue here is the ordering. The use of a
BTreeMapnot only deduplicates but also re-orders the types to follow the ordering of theInstanceTypeenum fromschemarswhich puts theNumbertype before theIntegertype.This makes the
Integervariant of ourValueenum here unreachable as all possible values can already be matched by theNumbervariant.I believe that forcing the re-ordering of the variant instead of following the ordering declared in the schema is a good thing but it should be slightly tweaked.
This PR introduces an intermediate re-definition of this
InstanceTypeenum with re-ordered fields and uses it for this BTreeMap deduplication.This in terms, gives us the following rust enum definition: